Repository navigation
fix(attackshark): enable the X11 on the rebuilt Bridge config path - #174
Merged
Merged
Conversation
A genuine X11 (0xfa60, receiver model id 0x55) over OpenMouse Bridge was refused by X11_REBUILT_CONFIG_MODELS, which only listed the Delux M600 Pro, so x11ConfigReachable stayed false and the mouse was status-only even though Bridge can reach the vendor feature reports. This is the failure reported in issue #161. Add 0x55: same receiver, protocol and rebuilt transport as the verified M600 Pro, with the receiver's documented 56-byte DPI frame. Models whose frame shape is not established (R1, X3, X6) stay read-only. The Bridge diagnostic is recorded under captures/attackshark-x11/. The write still wants confirmation on X11 hardware before release. Refs #161
5 tasks
|
🎉 This PR is included in version 0.26.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
snekxs
added a commit
that referenced
this pull request
Oct 10, 2026
…I curves (#188) * docs(attackshark): add X11 testing notes from issue #161 Records the Bridge diagnostic shape, the #174 rebuilt-config enablement for model 0x55, and the reporter's post-merge evidence, with the still-open unknowns (no measured DPI round-trip on genuine X11 hardware, wired path untested). * feat: Logitech DFU groundwork (placeholder) drivers/logitech/dfu.ts: depot archive + dfu.json parsing and validation, SHA256-gated binary resolution, interfaceId matching, numeric version compare, flashing safety gates (explicit confirm, verified hash, wired-only enforcement), and a bootloader transport seam carrying no invented wire bytes. hidpp.ts: experimental receiver firmware read via HID++ 1.0 register 0xF1 with per-MCU/index sweep and dedicated waiter plumbing that cannot collide with 2.0 traffic. vendors.ts: bootloader-mode USB PIDs observed adjacent to the vendor agent's Yeti bootloader binding. tsconfig: add the missing @openmouse/protocol/redragon path mapping — without it the whole logitech test file fails to load on a stale-dist import. * fix(logitech): keep receiver F1 MCU readout raw * docs: correct receiver 0xF1 semantics, record live bootloader PID Post-flash evidence (identical 0xF1 bytes across a real 14.3.19 -> 14.4.20 update) proves the register reports per-MCU bootloader identifiers, not app versions. Reframed accordingly so the decode is never used for version verdicts. Also records 046D:AB24 as the live-observed PRO LIGHTSPEED bootloader PID alongside the string-observed 0ADx set. * feat(finalmouse): add Starlight X TMR-DS, PAW LOD, profiles and signal support Reverse-engineered from xpanel 2.6.2 (SLX dongles 361D:0300/0301, output report 0x01): click mode (31), TMR actuation/MSP (53/55), PAW lift-off (25), profiles (57/58/61/62/63) and RSSI signal mapping. ULX report flow is byte-identical to before. SLX paths are marked unverified pending hardware testing (see docs/finalmouse-testing.md). * feat(wallhack): add M-001 buttons, macros, rotation, scan mode and DPI curves Button bindings (GET_KEYS/SET_KEYS, 8 triplet slots), onboard macros (GET_MACRO/SET_MACRO, 4 slots x 30 steps with device-side allocation), sensor rotation degrees, HIGH/ACCEL scanning mode, dynamic sensitivity curves (4 tables) plus enable/mode/reporting, u16LE sleep timer, and remapper label round-trips. Wire formats reverse-engineered from the WALLHACK Terminal bundle; hardware verification still pending. --------- Co-authored-by: snekxs <snekxs@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Genuine X11 units (
0x1d57:0xfa60, receiver model id0x55) were refused byX11_REBUILT_CONFIG_MODELS, which only listed the Delux M600 Pro (0x20). Over OpenMouse Bridge the rebuilt config collection carries no report sizes, sox11ConfigReachablestayed false and the mouse was status-only even though Bridge can reach the vendor feature reports - the failure in #161.Add
0x55: it rides the same receiver, protocol and rebuilt transport as the verified M600 Pro and resolves to the receiver's documented 56-byte DPI frame (x11UsesShortDpiReportreturns the long form for0xfa60). Models whose frame shape is not established (R10x10, X30x4d/0x4e, X60x85) stay read-only.Evidence: the reporter's Bridge diagnostic is recorded under
captures/attackshark-x11/; the packet shapes are the ones already verified through Bridge for the M600 Pro (captures/delux-m600-pro/windows-bridge.txt).The write has not yet been observed on X11 hardware. @sLimbutin - could you confirm DPI, polling and battery on a build of this branch before we call it done?
Refs #161